\chapter{Introduzione}

Nell'era di Internet e della globalizzazione dell'informazione le necessità di
coloro che utilizzano il software per svolgere le loro attività primarie sono
cambiate drasticamente. Per le grandi organizzazioni (siano queste aziende
private, pubbliche amministrazioni o altro) risulta indispensabile avere un
modello di attività dinamico e aperto che possa permettere loro di modificare
rapidamente le politiche e le strategie, e di dialogare in maniera sicura ed
efficiente con il maggior numero di partner e clienti. \`E quindi ovvio che la
risposta del mondo del software e della tecnologia non potesse che muoversi in
tal direzione. 

Il primo passo è stato quello di creare, tramite processi condivisi, gli standard
pubblici che permettessero di ideare una ``lingua franca'' tramite cui scambiare
l'informazione. La creazione dello standard XML \cite{XML} ha permesso di
descrivere i dati tramite una rappresentazione testuale che autoesplicita lo
schema di encoding utilizzato per rappresentare i caratteri in sequenze di byte.
In questo modo si è realizzata la completa indipendenza dei dati dalle specifiche
architetture hardware/software e l'informazione è diventata finalmente portabile
attraverso le diverse piattaforme. Insieme alla necessità di rappresentare i dati
a basso livello vi è sempre quella di poterli strutturare in tipi e forme sempre
più complessi. DTD \cite{XML10} prima, e XML Schema \cite{XMLSchema} poi, in
maniera definitiva, hanno permesso di risolvere brillantemente tale problematica
nell'ambito di XML stesso.

A questo punto avendo modo di rappresentare l'informazione in maniera totalmente
portabile e tipata ci si è rivolti ad individuare un modello di comunicazione che
permettesse lo scambio di tale informazione. \`E stata individuata l'astrazione
di ``servizio'', inteso semplicemente come un'interfaccia formalmente specificata
ad una risorsa puramente \emph{stateless}. Il concetto di ``risorsa'' è da
intendersi in senso generale, come un documento statico, ma anche come unità
elaborativa capace di restituire dinamicamente dei dati in base al valore di
parametri ricevuti in input.

La definizione della specifica formale dei servizi non poteva avvenire che
nell'ambito di XML e XML Schema e l'introduzione di WSDL \cite{WSDL}, linguaggio
direttamente basato su questi standard, ha permesso la realizzazione di
interfacce in cui si definiscono operazioni i cui parametri di input ed output
sono formalmente tipati e la loro descrizione astrae completamente dalle
tecnologie utilizzate per implementarle. Mentre WSDL rappresenta le interfacce,
SOAP \cite{SOAP} e WSDL Binding \cite{WSDL} definiscono il modo in cui l'informazione
che transita per tali interfacce viene strutturata e ``imbustata'' in messaggi. A
questo punto non rimane altro che determinare il mezzo con cui inviare tali
messaggi. E la scelta più ovvia non poteva che essere quella di utilizzare i
mezzi più diffusi e collaudati, ovvero HTTP \cite{HTTP} \cite{HTTP1} e i
protocolli di Internet.

Servizi basati sull'utilizzo combinato di XML, XML Schema, WSDL, SOAP e HTTP
sono in generale individuati col termine ``Servizi Web'', anche se spesso con
tale termine si tende a definire una classe più ampia di Servizi non necessariamente basati su tutte le
precedenti tecnologie.

Avere delle specifiche con un così alto livello di descrizione formale, fa sì
che sia possibile realizzare strumenti per la creazione
automatica di ampie parti di codice in vari linguaggi di programmazione. In
pratica, semplicemente dalla definizione di un dato servizio è possibile creare
parte dell'implementazione di esso o parte dei client. Questa è stata una della
caratteristiche che hanno contribuito maggiormente alla diffusione dei Servizi
Web ed a determinarne il successo.

Disporre di un sistema di comunicazione così promettente ha fatto sì che si
cominciasse ad utilizzarlo per definire un nuovo paradigma di programmazione e di
sviluppo di applicazioni, in cui al concetto di servizio si dovesse
inevitabilmente affiancare il concetto di stato (tutti sanno che per realizzare
applicazioni poco più che banali è indispensabile mantenere uno stato). Tale
paradigma è noto con il nome di SOC (Service Oriented Computing) \cite{SOC1}
\cite{WEBSERVICES}. In pratica, SOC racchiude tutte quelle attività tese alla
definizione di un modello di sviluppo software basato sull'assemblaggio di
componenti che possono essere specificati tramite i formalismi dei servizi ma che
possono eventualmente mantenere anche uno stato. WS-Addressing
\cite{WS-Addressing}, per esempio, è una tecnologia che contribuisce alla
definizione del concetto di stato all'interno degli standard dei Web Service.

In SOC, oltre al concetto fondamentale di servizio, confluiscono diverse
metodologie per la realizzazione delle funzionalità più complesse tramite la
composizione di funzionalità più semplici offerte dai servizi componenti. Per
esempio, un approccio che sta avendo un discreto successo è quello identificato
con il termine \emph{Business Process Oriented Approach}, secondo cui ogni
attività aziendale\footnote{Il termine aziendale deve essere inteso in senso
generale di organizzazione o di entità in cui più soggetti collaborano per il
raggiungimento di un fine comune secondo regole e strategie condivise.} deve
avere un preciso obiettivo (per esempio, mettere a disposizione un prodotto o un
servizio eventualmente anche solo per altre attività) e un ciclo di vita formale,
secondo cui, ad un evento di inizio attività (istanziazione del processo), deve
corrispondere un'evoluzione e un esito sempre individuabile come positivo o
negativo.

Ogni attività è quindi un processo composto da una serie di passi, visti
esternamente come unità atomiche, ma che in realtà possono racchiudere a loro
volta sottoprocessi (composizionalità), che vengono svolti secondo regole di
evoluzione precise (workflow) che ne stabiliscono le dipendenze logiche e
temporali. Le sottoattività utilizzate da un processo possono spaziare
nell'intero dominio aziendale ed essere svolte sotto la responsabilità di diverse
figure dell'organigramma societario. I tempi di evoluzione delle attività possono
essere in generale fortemente variabili e dipendenti da innumerevoli fattori. In
tal senso i processi, pur trovandosi spesso a dover garantire stringenti
requisiti temporali, devono fare i conti con sottoattività particolarmente riluttanti a
rispettare specifici vincoli temporali.

% A livello informatico
Nell'ambito di SOC, tale metodologia ha trovato attuazione
utilizzando i Servizi Web come tecnologia, sia per la realizzazione delle interfacce delle
attività, sia per la rappresentazione e la comunicazione dei dati, e
sviluppando un linguaggio come BPEL \cite{BPEL11Spec} per la codifica dei
workflow dei processi. Tale linguaggio permette di utilizzare i Servizi Web per
accedere alle sottoattività e, a sua volta, espone il processo stesso come un Servizio Web,
permettendo di realizzare la composizionalità e uniformando il modo in cui ogni
risorsa è vista esternamente. Come si può intuire, un linguaggio come
BPEL risulta uno strumento molto complesso, ricco di costrutti sia per la gestione
dei flussi interni che per la realizzazione della comunicazione.
% In particolare risulta critico la realizzazione su tempi lunghi e fortemente
% variabili di transazioni aziedali () \ldots

In pratica riguardo a BPEL risulta difficile sia realizzarne implementazioni a
partire dalle specifiche del linguaggio, sia utilizzare queste ultime per
sviluppare applicazioni. Attualmente BPEL è specificato da documenti, scritti in
linguaggio naturale, prodotto di un processo di standardizzazione supervisionato
da Oasis \cite{OASISSite}. L'assenza di una semantica formale può far sì che si
creino dei fraintendimenti e che ci possano essere interpretazioni diverse del
medesimo concetto, facendo sì che le implementazioni infine risultino
incompatibili. Per esempio, possono risultare di difficile interpretazione la
relazione fra le \emph{Multiple Start Activity} e il meccanismo di gestione dei
conflitti nell'attribuzione dei messaggi alle diverse istanze concorrenti di
un processo, o alcuni aspetti legati alle problematiche di
terminazione delle attività e di compensazione.

Il processo di realizzazione di applicazioni BPEL risulta difficile e fortemente
soggetto ad errori anche per la presenza di caratteristiche complesse quali:
parallelismo, concorrenza, terminazione forzata di attività, correlazione e
compensazione, quest'ultima utilizzata per la realizzazione di ``Long-Running
Transaction'', e forse ancora non compresa in tutti i suoi aspetti e potenzialità
dagli utilizzatori. In tal senso un processo di analisi e di
formalizzazione di tali costrutti è certamente utile, sia per chi si trova ad
utilizzarli, sia per coloro che ne realizzano l'implementazione a partire da
specifiche in linguaggio naturale, in modo tale da renderne più chiaro il
significato ed eventualmente semplificarne gli aspetti più delicati.

Un approccio, per cercare di affrontare queste problematiche, è stato quello di
utilizzare i metodi formali e la teoria delle ``algebre di processo'' per la
definizione di una semantica formale e per la realizzazione successiva di una
piattaforma per la verifica e la dimostrazione di proprietà di applicazioni
basate su BPEL. Con tale scopo è stato ideato Blite \cite{LaPuTie1}, una
variante semplificata di BPEL, che riproduce alcune delle sue funzionalità più
caratteristiche, cercando d'altra parte di semplificare alcuni aspetti ritenuti
marginali nella realizzazione del modello Process Oriented. In definitiva in
Blite è stato selezionato un core di BPEL, per cui fosse abbastanza agevole
definire una semantica formale e con cui, tramite ``encoding'', fosse possibile
sostanzialmente riproporre tutte le funzionalità del linguaggio.

Il lavoro svolto in questa tesi è da considerarsi a supporto di tale attività,
come un'ulteriore verifica e confronto del processo di astrazione teorica e
formale con gli aspetti più concreti e tecnologici, legati all'implementazione di
un linguaggio per l'orchestrazione distribuita di servizi. Infatti l'obiettivo
primario è stato quello di realizzare un'implementazione di Blite che potesse
essere il più vicino possibile, per caratteristiche ed applicabilità, ai motori
di esecuzione di BPEL attualmente disponibili. Se da un lato Blite vuole essere
un'analisi di BPEL, fatta tramite un processo di astrazione e formalizzazione,
il lavoro qui esposto vuole essere a sua volta un'analisi di tale processo, nel
senso che ne vuole verificare la compatibilità e l'attinenza con le problematiche
più concrete e tecnologiche presenti nell'ambito dell'orchestrazione di servizi.
Di fatto il lavoro svolto rappresenta un test critico di come i costrutti
formali, utilizzati per fornire la semantica del linguaggio, possano essere realmente
implementati in scenari di software di produzione e che quindi continuino a
mantenere un legame a doppio filo con il mondo delle tecnologie, da cui hanno
tratto iniziale ispirazione. 

Oltre che nella direzione sopra esposta, la nostra attività di verifica di
Blite si è mossa verso la creazione di strumenti che possano permettere
direttamente di scrivere e simulare in maniera rapida processi definiti con
esso. Ci è sembrato che un modo molto utile per verificare la funzionalità del
linguaggio creato, fosse quello di poter scrivere ed eseguire programmi e di avere una
rappresentazione, il più espressiva possibile, dell'avvenuta esecuzione e di
come si sia attuata la comunicazione tra i processi.

In pratica sono stati realizzati due progetti software basati su tecnologia
Java \cite{Java}: \emph{Blite-se} e \emph{Blide}. 

\textbf{Blite-se} (Blite Service Engine) realizza l'insieme delle funzionalità
necessarie alla esecuzione di processi definiti tramite Blite, o meglio, tramite
una sintassi leggermente modificata. In particolare fornisce un compilatore
(realizzato con la tecnologia JavaCC e JJTree \cite{JavaCC}) e un modello
statico per la rappresentazione dei programmi. Il compilatore, come risultato
dell'analisi sintattica, produce un modello ad oggetti rappresentante il programma stesso.
Tale modello, di seguito riferito come \emph{Modello Statico}, è in pratica
l'albero sintattico i cui nodi sono oggetti che espongono funzionalità
specifiche, in base alla categoria sintattica rappresentata.

In Blite-se è realizzato anche il motore (\emph{Engine}) per l'esecuzione dei
processi secondo la semantica formale definita in \cite{LaPuTie1}. Tale
componente software è stata progettata in riferimento a specifiche che tenessero
il più possibile conto delle problematiche reali degli ambiti produttivi
(efficienza, scalabilità, requisiti di memoria, ecc). \`E stato ideato inoltre,
un modello di esecuzione basato sul pattern \emph{Composite} \cite{GANGo4},
secondo cui ogni attività è rappresentabile come un componente che apporta il
proprio contributo all'esecuzione dell'istanza di processo. A partire dal modello
statico, a runtime viene costruito passo passo un \emph{Modello Dinamico},
l'albero dei componenti/attività, e l'esecuzione procede tramite l'invocazione
ricorsiva del metodo \icode{doActivity()} su tali camponenti. In sintesi, il
nostro modello di esecuzione può essere definito \emph{Activity Centric}, nel
senso che le varie attività saranno responsabili nel realizzare la loro
esecuzione, ma anche nel collaborare, per far sì che i flussi globali dei
processi evolvano secondo quanto specificato dalla semantica.

L'Engine è stato realizzato astraendo dagli aspetti più concreti e
tecnologici, quali la comunicazione e il deployment. L'Engine, per comunicare
con le porte dei servizi esterni, utilizza un'interfaccia
(\icode{EngineChannel}), che definisce un modello di comunicazione totalmente
generico, utilizzabile per realizzare molteplici protocolli per lo scambio di
messaggi, dal più semplice \emph{``fire and forget''} ai più complessi, che necessitano un
mantenimento dello stato. Le implementazioni di tale interfaccia verranno fornite
dal componente software \emph{Environment}, che realizza un contenitore per
l'Engine nell'ambito di una precisa tecnologia di comunicazione. 

Attualmente è stato creato un \emph{Local Environment} capace di eseguire
localmente più Engine e simulare la rete e la comunicazione remota, ma sarebbe
interessante realizzare Environment capaci di supportare direttamente gli
standard tipici della tecnologia dei Servizi Web, come WSDL, SOAP e HTTP, e poter
quindi far dialogare i nostri programmi Blite con ogni servizio disponibile in
Internet. Altre possibilità potrebbero essere quelle di avere Environment capaci
di supportare lo standard JBI \cite{JBI} e poter integrare il nostro Engine con
ESB (Enterprise service bus) che supportano tale tecnologia; o Environment
integrabili con framework per la comunicazione remota come \emph{IMC} \cite{IMC}.
\\

\textbf{Blide} (Blite Integrated Development Environment) costituisce il
secondo progetto software realizzato. Esso implementa un
vero e proprio IDE che permette di scrivere rapidamente e testare, tramite
l'esecuzione di simulazioni, i programmi Blite. Oltre alle consuete
funzionalità di gestione ed editing dei file, compilazione ed esecuzione
integrata dei programmi, Blide fornisce un formalismo e una tecnologia per la
rappresentazione grafica dell'esecuzione delle istanze e la comunicazione fra
esse. In pratica le varie istanze vengono monitorate durante la loro esecuzione
e vengono memorizzate le informazioni necessarie a darne una rappresentazione
grafica. Alcune parti dell'interfaccia grafica mostrano all'utente le varie
istanze eseguite e in esecuzione, cosicché l'utente può scegliere fra le istanze
andando a comporre rappresentazioni della loro interazione.

Blide è stato realizzato tramite il progetto \emph{NetBeans Platform}
\cite{NBPlatSite}, un framework studiato per facilitare lo sviluppo di applicazioni
Java con interfaccia grafica. \`E stato scelto tale progetto per la sua
completezza e per il modello architetturale offerto. 

NetBeans Platform permette allo sviluppatore di realizzare le proprie
applicazioni componendo diversi moduli, ciascuno dei quali offre una
funzionalità specifica. La modularizzazione molto fine e la gestione
formale delle dipendenze permettono di costruire applicazioni riuscendo a
selezionare in modo molto mirato solamente i moduli realmente necessari e
quindi a mantenere limitate le dimensioni complessive dell'applicazione. 
In questo modo è stato possibile realizzare un modello di distribuzione
dell'applicazione basato su Java WebStart \cite{JavaWS}, tramite il quale gli
utenti possono eseguire, istallare e aggiornare in maniera trasparente l'applicazione
da una pagina Web, semplicemente selezionando un link. Dalla pagina 
\emph{http://code.google.com/p/blite-se/} è possibile istallare e mettere in
esecuzione la versione più recente di Blite sulla propria macchina,
per poi effettuare eventualmente anche esecuzioni offline.
\\

Tutto il progetto software realizzato per questa tesi è disponibile online alla
pagina \emph{http://code.google.com/p/blite-se/}, da cui è possibile ottenere le
distribuzioni binarie, la documentazione e i sorgenti. Questi ultimi sono
gestiti con la tecnologia \emph{SVN} \cite{SVN}, messa a disposizione da
\emph{Google} tramite il progetto \emph{Google Code} \cite{GCode} e sono rilasciati
sotto la licenza \emph{GNU General Public License v3} \cite{GPLv3}.
\\

% Disponendo di un client SVN (esistono implemetazioni per le più diffuse
% architetture e sistemi operativi) l'intero codice del progetto (Blite-se e Blide) può essre
% ottenuto con il comando
% 
% svn checkout http://blite-se.googlecode.com/svn/trunk/ blite-se-read-only

Dopo aver presentato una panoramica delle motivazioni e del lavoro da noi svolto
andiamo a illustrare i contenuti di questa tesi. Nel Capitolo 2 viene introdotto
il linguaggio BPEL per l'orchestrazione di servizi, partendo da una
presentazione ad alto livello dei suoi costrutti caratteristici; successivamente viene presentato
Blite, fornendone sintassi e semantica operazionale.
L'implementazione del compilatore per Blite necessita di una grammatica formale,
e nella Sezione \ref{gram} vengono presentati i procedimenti che ci hanno portato ad
ottenerla, a partire dalla sintassi astratta definita in Sezione \ref{sec:blite}. Il
capitolo si chiude con una sezione in cui vengono commentati alcuni aspetti
della semantica rispetto alle problematiche d'implementazione.

Nel Capitolo 3 viene presentato il progetto software Blite-se. Dopo aver
fornito una panoramica del progetto e dei principali moduli che lo compongono si
presenta nel dettaglio l'architettura del motore di esecuzione, mettendo in
evidenza il modello per le attività, la gestione del parallelismo e della
comunicazione, l'implementazione dei contesti, con la gestione delle
eccezioni e della compensazione.

Il Capitolo 4 fornisce una panoramica delle funzionalità offerte da Blide e
dalla sua interfaccia utente e si conclude con la presentazione di un semplice
caso d'uso. 

Il Capitolo 5 presenta un riepilogo critico del lavoro svolto e si delinea i
possibili sviluppi ulteriori.
